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REMARKS 

The Examiner is thanked for the performance of a thorough search. Claims 1-21, 23-26, 
and 28-32 are pending in this application. The amendments to the claims do not add any new 
matter to this application. Furthermore, the amendments to the claims were made to improve the 
readability and clarity of the claims and not for any reason related to patentability. All issues 
raised in the Office Action mailed December 2, 2008 are addressed hereinafter. 

I. ISSUES NOT RELATING TO PRIOR ART 

A. CLAIM REJECTIONS - U.S.C. § 101 

The Office Action rejected claims 9, 23 and 30 under 35 U.S.C. § 101. (Office Action, 

page 3) 

Applicants believe that the rejection is fully addressed by amended claims 9, 23 and 30. 
Reconsideration and withdrawal of the rejection is respectfully requested. 

II. ISSUES RELATING TO PRIOR ART 
A. CLAIMS - 35 U.S.C. § 102(e): HO 

Claims 1-2, 6-11 and 15-18 stand rejected under 35 U.S.C. § 102(e) as allegedly 
unpatentable over Ho Pub. No. US 2002/0136223 Al (hereinafter "Ho"). (Office Action, page 
4) The rejection is respectfully traversed. 

CLAIM 1 

Present claim 1 recites: 

1 . A method of forwarding a tunneled packet having a header identifying a tunnel end point 
and a payload, in a data communications network, comprising the steps performed at a 
forwarding node of: 
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for a forwarding node and a tunnel end point both in the same data communication 
network and both transmitting tunneled packets using the same data 
communication protocol: 

recognizing a tunneled packet comprising an address directly identifying a 

neighbor node to the forwarding node as the tunnel end point; 
removing the header and 

forwarding the payload to the neighbor node using the address directly 
identifying the neighboring node and without a lookup of a 
forwarding address. 

Support for the amendment to claim 1 is provided in paragraph [0043] of the 
specification. 

In the previous Reply, applicants argued that Ho's ATM interface, comprising an 
"ingress ATM aware LSR" and an "egress ATM aware LSR," is not "a forwarding node and a 
tunnel end point both in the same communication network, and both transmitting tunneled 
packets, using the same data communication protocol," where the forwarding node 
recognizes a tunneled packet comprising an address directly identifying a neighbor node to 
the forwarding node as the tunnel and point," "removes the header," and "forwards the 
payload to the neighbor node using the address directly identifying the neighboring node 
and without a lookup of a forwarding address," as claimed. 

The Office Action agrees with applicants that Ho's ATM interface does not recite the 
above limitations. (Office Action, Response to Arguments Section, page 1 1) However, the 
Office Action states that "it is [Ho's] forwarding node 16d of FIG. 2 that performs the above 
limitations." (Office Action, page 11) This is incorrect. 

Ho's forwarding node 16d is a typical MPLS penultimate node and can only act as a 
typical penultimate node, not as the forwarding node recited in claim 1. Ho's penultimate 
node 16d forwards a packet to the egress ATM aware LSR. Ho's node 16d allows penultimate 
hop popping to remove need for extra lookup at an "ATM aware LSR, " (Ho: FIG. 2, paragraph 



50325-0807 (Seq. No. 7345) 



14 



Bryant, Serial No. 10/620,866 filed 07/15/2003 
GAU 2619, Examiner A. Sol 
Reply to Office Action 

[27], 11. 1-12), not at the penultimate node itself. In Ho, after the penultimate node 16d pops off 
the outer encapsulating header, it cannot "forward the payload to the neighbor node (node 16b) 
using the address directly identifying the neighboring node and without a lookup of a 
forwarding address," as claimed. 

As a typical penultimate node, Ho's node 16d, after removing the header, has to 
perform further lookups before it can forward the payload to the neighbor node," which is 
directly opposite to what is recited in claim 1. In an MPLS network, upon receiving a tunneled 
packet, a penultimate node must perform two lookups. The first lookup is performed when the 
penultimate node receives a packet, and requires processing the outer encapsulating IP header to 
verify that the packet was indeed meant to the penultimate node. The second lookup is 
performed to determine whether the next node to which the packet needs to be sent is an egress 
node. In an MPLS network, every node along the path, with the exception of the egress node, 
performs these two lookups. Therefore, after removing the header (which requires the first 
lookup), Ho's penultimate node must perform the second lookup, and cannot "forward the 
payload to the neighbor node using the address directly identifying the neighboring node and 
without a lookup of a forwarding address," as claimed. 

After removing the outer encapsulating header, Ho's node 16d must perform the 
second lookup to determine whether it received an advertisement indicating that the next 
node is an egress node. The egress node 16b knows that it is the egress node because it is 
manually or automatically configured to know that. However, a penultimate node 16d for a 
particular LSP does not know that it is the penultimate node unless it receives an advertisement 
from the egress node 16b. The egress node 16b needs to send to the penultimate node 16d an 
advertisement with an implicit-null label for a given FEC. The information from the 
advertisement is recorded in the penultimate node's RIB, and needs to be looked up before the 
penultimate node 16d can forward the payload to the egress node 16b. Therefore, after removing 
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the outer encapsulating header, Ho's penultimate node 16d cannot forward the payload to the 
egress node unless it performs the second lookup. This is opposite to what is recited in claim 1. 

Ho does not teach or suggest more than one level of encapsulation, and thus requires 
only one tunnel endpoint, which is not required by claim 1. Ho teaches that only one tunnel is 
established for a particular packet path, and the tunnel endpoint is the egress node 16b. (Ho: FIG. 
2; paragraph [28]) Thus, Ho has only one tunnel endpoint 16b and only one penultimate node 
16d. In Ho, only one penultimate node 16d can forward the packet to the tunnel end point 16b. 
Therefore, Ho teaches that no other node besides the egress node 16b can be a tunnel end point. 
Further, Ho teaches that no other node besides the penultimate node 16d can forward the packet 
to the tunnel end point. 

In contrast to Ho, claim 1 recites that any node, not just an egress node, can be a tunnel 
end point, and thus, contrary to Ho, claim 1 allows multiple layers of encapsulation along a path. 
Further, in contrast to Ho, claim 1 recites that any node, not just a penultimate node, can be a 
forwarding node. Moreover, in contrast to Ho, claim 1 recites that any forwarding node, after 
"removing the header identifying the tunnel end point, forwards the payload to the 
neighboring node using the address directly identifying the neighboring node and without a 
lookup of a forwarding address." Thus, according to claim 1, any forwarding node, after 
removing the header identifying the tunnel end point, without any further lookups, forwards the 
payload to the next node, which does not have to be an egress node. 

Further, according to claim 1, there may be a number of forwarding nodes and a number 
of tunnel end points along one path, forming a set of sequentially concatenated tunnels within the 
path. Each of the forwarding nodes recited in claim 1 can receive a packet encapsulated at a 
certain level of encapsulation, remove the outer encapsulated header and then forward the 
payload to the neighboring node (which does not have to be an egress node) without any further 
lookup. These features are not taught or suggested in Ho. 
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In the previous Reply, applicants argued that Ho's ingress ATM aware LSR is not a 
"forwarding node" that after "removing a header," directly "forwards the payload to the 
tunnel end point using the address directly identifying the neighboring node and without a 
lookup of a forwarding address," as claimed. The Office Action agrees with applicants. 
(Office Action, Response to Arguments Section, page 11) However, the Office Action states 
that "it is the forwarding node 16d of FIG. 2 that performs the above limitations." (Office Action, 
page 11) This is incorrect. 

As discussed above, Ho's node 16d is a typical MPLS penultimate node and thus, after 
removing the outer encapsulating header, it must perform further lookups before it forwards the 
packet to the egress node. (See above, pages 14- 1 5) Further, as discussed above, without 
performing a lookup, after removing the outer encapsulating header, the penultimate node 16d 
would not know that the next node is an egress node, would not perform penultimate hop 
popping and would not remove the need for extra lookup at the egress ATM aware LSR. (Ho: 
FIG. 2) Therefore, as discussed above, Ho's penultimate node 16d is not the forwarding node 
as recited in claim 1 . 

In the previous Reply, applicants argued that Ho's ingress ATM aware LSR and the 
neighboring MPLS nodes are not a "forwarding node and a tunnel end point," where the 
"forwarding node recognizes a tunneled packet comprising an address directly identifying 
the neighbor node to the forwarding node as the tunnel end point, removes any header," 
and "forwards the payload to the tunnel end point using the address directly identifying the 
neighboring node and without a lookup of a forwarding address," as claimed. The Office 
Action agrees with applicants. (Office Action, Response to Arguments Section, pages 11-12) 
However, the Office Action states that "MPLS node 16d of FIG. 2 is a forwarding node and the 
egress ATM aware LSR 16b is the tunnel end point that performs the above steps. (Office 
Action, pages 11-12) This is incorrect. 
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As discussed above, Ho's node 16d is a typical MPLS penultimate node and thus, after 
removing the outer encapsulating header, it must perform further lookups before it forwards the 
packet to the egress node. Thus, Ho's node 16d is not the "forwarding node that, after 
removing the header, forwards the payload to the neighbor node using the address directly 
identifying the neighboring node and without a lookup of a forwarding address," as recited 
in claim 1. (See above, pages 14-15) 

In a previous Reply, applicants established that Ho's egress ATM aware LSR is not a 
"forwarding node" that after "removing a header,'' directly "forwards the payload to the 
tunnel end point using the address directly identifying the neighboring node and without a 
lookup of a forwarding address," as claimed. The Office Action agrees with applicants. 
(Office Action, Response to Arguments Section, page 13) However, the Office Action states 
that the penultimate node 16d of FIG. 2 performs the above limitations." (Office Action, page 13) 
This is incorrect. 

As discussed above, Ho's node 16d is a typical MPLS penultimate node and thus, after 
removing the outer encapsulating header, it does perform further lookups before it forwards the 
packet to the egress node. (See above, pages 14-15) Therefore, as discussed above, Ho's 
penultimate node 16d is not the "forwarding node" that after "removing a header," directly 
"forwards the payload to the tunnel end point using the address directly identifying the 
neighboring node and without a lookup of a forwarding address," as claimed. 

Therefore, claim 1 recites one or more features that are not described in Ho. Thus, 
anticipation is unsupported, and reconsideration and withdrawal of the rejection is respectfully 
requested. 

CLAIMS 9-10 AND 18 
Claims 9-10 and 18 recite features similar to those in claim 1. Therefore, reconsideration 
and withdrawal of the rejection is respectfully requested for the same reasons described for claim 
1. 
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B. CLAIMS - 35 U.S.C. § 103(a): HO, AKAHANE 

Claims 3-5, 12-14, 19-21, 23-26 and 28 stand rejected under 35 U.S.C. § 103(a) as 
allegedly unpatentable over Ho Pub. No. US 2003/0053414 Al (hereinafter "Akahane"). (Office 
Action, page 6) The rejection is respectfully traversed. 

CLAIMS 19, 23-24 AND 28 

Claims 19, 23-24 and 28 recite features similar to those in claim 1, and Ho does not teach 
or suggest the whole subject matter of claim 1 because, as discussed above, none of Ho's nodes 
is the "forwarding node" that after "removing a header," directly "forwards the payload to 
the tunnel end point using the address directly identifying the neighboring node and 
without a lookup of a forwarding address," as claimed. Further, Akahane does not cure the 
deficiencies of claim 1. Therefore, reconsideration and withdrawal of the rejection is 
respectfully requested for the same reasons described for claim 1 . 

DEPENDENT CLAIMS 

The claims that are not discussed above depend directly or indirectly on the claims that 
have been discussed. Therefore, those claims are patentable for the reasons given above. In 
addition, each of the dependent claims separately introduces features that independently render 
the claim patentable. However, due to the fundamental differences already identified, and to 
expedite positive resolution of the examination, separate arguments are not provided for each of 
the dependent claims at this time. 

III. CONCLUSIONS 

It is respectfully submitted that all of the pending claims are in condition for allowance 
and the issuance of a notice of allowance is respectfully requested. 

If any applicable fee is missing or insufficient, the Commissioner is authorized 
throughout the pendency of this application to charge any applicable fee to our Deposit Account 
No. 50-1302. 
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The Examiner is invited to contact the undersigned by telephone if the Examiner believes 
that such contact would be helpful in furthering the prosecution of this application. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 



Date: January 7, 2009 /MalgorzataAKulczycka#50496/ 

Malgorzata A. Kulczycka 
Reg. No. 50,496 

2055 Gateway Place, Suite 550 
San Jose, California 95 1 10 
Telephone: (408) 414-1228 
Facsimile: (408)414-1076 
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